Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9611/000056_owner-urn-ietf _Wed Nov 6 09:31:24 1996.msg

Internet Message Format | 1997-02-19 | 9KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA09099 for urn-ietf-out; Wed, 6 Nov 1996 09:31:24 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA09094 for <[e-mail]>; Wed, 6 Nov 1996 09:31:20 -0500
Received: from zaphod.axion.bt.co.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA09817  (mail destined for [e-mail]); Wed, 6 Nov 96 09:30:56 -0500
Received: from mailhub.axion.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); Wed, 6 Nov 1996 14:30:10 +0000
Received: from kaa.jungle.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Wed, 6 Nov 1996 14:29:44 +0000
Received: from phao.jungle.bt.co.uk by kaa.jungle.bt.co.uk; Wed, 6 Nov 96 14:28:56 GMT
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 06 Nov 1996 14:31:06 +0000
To: Keith Moore <[e-mail]>
From: Bob Briscoe <[e-mail]>
Subject: Re: [URN] Resolution Services (N2L etc)
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
Reply-To: Bob Briscoe <[e-mail]>
Errors-To: [e-mail]

At 23:27 05/11/96 -0500, Keith Moore wrote:
>> 1.2 It strikes me that specifying available service requests (N2L, N2R etc)
>> should not be the job of DNS or any URN resolution mechanism. You are adding
>> metadata about the address that the name resolves to (i.e. allowed methods).
>> NAPTR should simply get you to the place you asked for by mapping names to
>> addresses.
>
>Not clear.  DNS is the place to store name-to-IP-address bindings.  If
>the different services (methods) are at different IP-addresses, the
>mappings between the names of the machines where the services reside,
>and their IP addresses will be managed by DNS.  And there's
>potentially a big efficiency win to having the name-to-service mapping
>lookup occur as a side-effect of an lookup that returns NAPTR records
>with an /s flag.

As long as everyone is clear that this is an efficiency hack, not a core
requirement, and of the potential consequential problems, the purpose of my
posting has been met.

However, I would like to propose a far cleaner alternative (backed up by a
load more words in the paper on URCs I'm about to put out) which doesn't
need any efficiency hacks because it removes the need to differentiate
between N2C, N2R etc. (and makes multi-collaborative working as easy as
single domain - I'll explain why this is a problem below)...

Lets take N2* first:

N2C: I would propose, that each address mapping you would intend to give as
a reply to an N2C or an N2L request, should each be given a different URN.
URNs are cheap. As soon as you tie any two things (that are not the same
thing) together under one name, you are doing the job of URCs not URNs.

If you insist, for instance, that the URC and the resource both have the
same URN, you are mandating that a URC must be authored with the permission
of the same domain of authority as the author of the resource itself (or
vice versa). This stops people *independently* publishing URCs about other
people's resources. Now where would the Web be today if you had to get
someone's permission to link to them?

N2R: I'm much less clear why there is a need to differentiate between N2L
and N2R in the first place. The name resolution service will give back a
location whatever. It's then up to the client to use it and the protocol it
specifies to access the resource if it wants, or not if it doesn't. Nothing
else would scale, and any protocol schemes that needed the name resolver
service to get resources for it should be killed at birth. Am I missing
something?

N2Ls & N2Rs: The plural versions are, IMHO, something that should be the
default for all clients using URNs, with singular responses just a special
case. All DNS BIND clients since some time in 1994 included round robin if
they got a list of responses back, so if your user-agent asked BIND for an
address it would get just one, but BIND would feed it another one if it
asked again. If the user-agent wanted the list directly, there would be
nothing stopping it implementing BIND internally.

I think I've now reduced all the N2* options to a singular case for each URN
- that is "N2Ls".

Moving on to the L2* options.

L2R, as I said under N2L & N2R (unless I'm missing something) is not the job
of URNs.

L2N is valid, but DNS already has a far more scalable solution by building a
reverse mapping tree topped by a well known name (in-addr.arpa). This could
be bent to do reverse NAPTR lookups. Effectively this makes and L2N into an
N2Ls.

L2L could be done with a reverse then a forward lookup.

L2C would be useful, but in practice is unattainable if you want to allow
multi-collaborative creation of URCs separate from resources. I have
resigned myself to losing this capability in my work on URCs. The only way
to do this is to rely on a harvester (like you have to do to find everyone
who links to you on the Web today - you put in the URL of your resource as a
query to the search engine).

So that's thrown out all the proposed L2* opions or reduced them to "N2Ls".

The bottom line is, you only need N2Ls or there are better ways to do this,
IMHO.

>
>> Other systems  (service discovery or navigation) should allow you to
>> determine what you *should* ask for from the address once you get it, and
>> once you have the address each protocol scheme might provide a well-known
>> method for querying what methods you *can* do if that is what the scheme
>> needs (e.g. HTTP/1.1 OPTIONS method).
>
>Only if all possible methods for a service are available at every
>service location.  You don't want to have to ask each service location
>which methods are available at that server.

See above.

>
>> IOW, the client should already know
>> what it is going to do with the address it gets out of the URN service, or
>> if it doesn't it should be prepared to find out.
>
>The client knows what it wants to do.  But how the client does what it
>wants to do may depend on what services are available.  If there are
>multiple resolution services available for a particular chunk of name
>space, it might be that several of them will do what the client wants.
>For example, if all a client wants is a URL, N2L might be more
>efficient than N2C.

Yes, you get efficiency, but at the expense of independence of
collaboration. It would be valid to take the N2* approach to identify the
"trusted" URCs if you wanted to do this, and still allow others to
independently have other URCs.

>
>> OK, it may be *easier* to hack it this way, but that's not the point. You
>> are embedding a duplication of meta-information in DNS which will always be
>> prone to being out of date, unreliable, etc. Especially if the world moves
>> to be much more dynamic in this area in the decades you envisage this
>> lasting. More importantly, this information potentially has a different TTL
>> than the address itself, so it will break your caching.
>
>I don't see what the problem is.  DNS can specify TTLs on a
>per-resource-record basis.

The problem is that the decision on the *value* for the TTL is easy if it
only relates to the life of the mapping. If it relates to the life of the
mapping *and* the life of all the resolution services within those mappings,
any potential for the automation of the generation of the TTL value has
multiple dependencies. The more complexity you introduce, the more problems
you get with distributed two phase commits, fraud modes etc. etc.

>
>At any rate, we should view the use of DNS for resolution as a
>short-term experiment rather than a long-term solution.  Viewed in
>that context, it's not important that we get every little detail
>right.

Architecture isn't detail. I'm having to define BT's Future Commercial
Internet Service Architecture on top of whatever you folks do. If I thought
this wasn't important, I would have just kept schtumm and continued to
listen to the URN stuff in read-only mode.

Bob
____________________________________________________________________________
Bob Briscoe         http://www.labs.bt.com/people/briscorj/index.htm